Remarks 



I. The Amendment to the Claims 
The Office communication states: 

2. The applicant is advised to correct the dependency of claims 47 and 48 
(claim 47 should depend on claim 46 and claim 48 should depend on 
claim 41), so that the claim tree of the pending application matches the 
claim's tree of the patent 6,246,683 (The applicant tried to fix the lack of 
antecedent issues by rewriting the dependency of the claims, but rather to 
change the indefinite article of the claim). 

Applicants have amended the claims as suggested by the Office Action. Claim 47 
has been amended to depend from claim 46 instead of from claim 44, and to include an 
indefinite article preceding the term "plurality of packets." Similarly, claim 48 has been 
amended to depend from claim 41 instead of from claim 45, and to include an indefinite 
article preceding the term "block of data." 

II. The Suggestion of Interference 
The Office communication states: 

3. The applicant is therefore advised to redraft the suggestion of the 
interference to correct the grouping of claims in the counts. 

The following is a redrafting of the suggestion of interference, taking into account 
the Amendment to the Claims. 

A. Identification of Interfering Claims 

Applicants submit that the following claims interfere with claims 1-9 of the '683 

patent: 

Pending claims 41-49. 

B. Proposed Counts 

As stated in the Reply dated January 27, 2010, applicants propose the following 
three coimts: 
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Count 1 . A method for transferring data on a network from a data source to an end 
station executing a multi-layer network protocol, including a network layer and at least 
one higher layer, through a network interface on the end station, comprising: 

receiving in the network interface a packet which carries a data payload 
from a block of data in the data source, and a confrol field identifying the packet; 

determining based on the control field in the network interface whether the 
packet matches communication control information, and if so fransferring the data 
payload in the packet directly to a target buffer assigned by a process at a layer higher 
than the network layer. 

Count 2. A method for fransferring data on a network from a data source to an end 
station executing a multi-layer network protocol, including a network layer and at least 
one higher layer, through a network interface on the end station, comprising: 

receiving in the network interface a packet which carries a data payload 
from a block of data in the data source, and a confrol field identifying the packet; 

determining based on the control field in the network interface whether the 
packet matches communication confrol information, and if so transferring the data 
payload in the packet directly to a target buffer assigned by a process at a layer higher 
than the network layer; 

including prior to receiving the packet, allocating the target buffer for a 
plurality of packets, and notifying the network interface of the allocated target buffer. 

Count 3. A method for transferring data on a network from a data source to an end 
station executing a multi-layer network protocol, including a network kyer and at least 
one higher layer, through a network interface on the end station, comprising: 

receiving in the network interface a packet which carries a data payload 
from a block of data in the data source, and a confrol field identifying the packet; 

determining based on the control field in the network interface whether the 
packet matches communication control information, and if so fransferring the data 
payload in the packet directly to a target buffer assigned by a process at a layer higher 
than the network layer; 
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wherein the network interface is coupled to a network medium supporting 
a maximum packet size, and including transmitting a request from an application for 
transfer of a block of data from the data source, the block of data having a length greater 
than the maximum packet size for the medium. 

C. Comparison of at least One Claim of Each Party to Each Count 

Count 1 above is the same as claim 1 of the '683 patent, except that the term 
"communication control information" is substituted for the term "flow specification" of 
the claim. Covmt 1 above is also the same as claim 41 of the present application, except 
that the term "communication control information" is substituted for the term "transmit 
control block (TCB)" of the claim. 

Count 2 above is the same as claim 4 of the '683 patent written in independent 
form, except that the term "communication control information" is substituted for the 
term "flow specification" of the claim, and the definite article "the" preceding the term 
"plurality of packets" in claim 4 is replaced with the indefinite article "a." Count 2 above 
is also the same as claim 44 of the '683 patent written in independent form, except that 
the term "communication control information" is substituted for the term "transmit 
confrol block (TCB)" of the claim. 

Count 3 above is the same as claim 5 of the '683 patent written in independent 
form, except that the term "commimication control information" is substituted for the 
term "flow specification" of the claims, and the term "potentially" is deleted in the Count. 
Coimt 3 above is also the same as claim 45 of the '683 patent written in independent 
form, except that the term "communication control information" is substituted for the 
term "transmit control block (TCB)" of the claim. 

D. Showing of Claim Correspondence to Counts 

The table on the following page shows how the claims in the present application 
and those of the '683 patent correspond to the Coimts. 
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Claim Correspondence to Counts 



Coxmt Number 


Claims in the '683 patent 
that correspond to the count 


Claims in the application 
that correspond to the count 


Count 1 


Claims 1-3, 8 and 9 


Claims 41-43, 48 and 49 


Count 2 


Claim 4 


Claim 44 


Counts 


Claims 5-7 


Claims 45-47 



E. Comparison of Each Party's Claims and the Counts 
Applicants below submit a claim chart comparing claims 1-9 of the '683 patent 
with the Counts, a claim chart comparing claims 41-49 of the present application with the 
Counts, and a claim chart showing why the claims interfere within the meaning of 37 
CFR 41.203(a). 

i. Claim Chart Comparing Claims 1-9 of the '683 Patent with the Counts 
Applicants submit the following claim chart comparing claims 1-9 of the '683 
patent with the Comts. 



'683 Patent Claim Correspondence to Counts 



Count 


Claims in the '683 patent that correspond to the Count 


Count 1 . A method for 
transferring data on a 
network from a data source 
to an end station executing 
a multi-layer network 
protocol, including a 
network layer and at least 
one higher layer, through a 
network interface on the 
end station, comprising: 

receiving in the network 
interface a packet which 


1 . A method for transferring data on a network from a 
data source to an end station executing a multi-layer 
network protocol, including a network layer and at least 
one higher layer, through a network interface on the end 
station, comprising: 

receiving in the network interface a packet which 
carries a data payload from a block of data in the data 
source, and a control field identifying the packet; 

detenmning based on the control field in the network 
interface whether the packet matches communication 
control information, and if so transferring the data payload 
in the packet directly to a target buffer assigned by a 
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carries a data payload from 
a block of data in the data 
source, and a control field 
identifying the packet; 

determining based on the 
control field in the network 
interface whether the packet 
matches communication 
control information, and if 
so transferring the data 
payload in the packet 
directly to a target buffer 
assigned by a process at a 
layer higher than the 
network layer. 


process at a layer higher than the network layer. 

Claim 1 is identical to Count 1, except for the term 
"communication control information" in the Count 
compared with the term "flow specification" in the claim. 

Applicants submit that Count 1 would have anticipated or 
rendered obvious claim 1, and vice- versa. For example, 
claim 7, which depends indirectly from claim 1, defines 
that the "flow specification" includes "a sequence number 
of a first byte from the plurality of packets to be stored in 
the target buffer." Similarly, claim 8, which depends from 
claim 1, defines that the "flow specification" includes "a 
sequence number for the block of data." Claim 9, which 
depends indirectly from claim 1, defines that the "flow 
specification" includes "IP source and destination 
addresses and TCP port numbers." A "sequence number 
of a first byte from the plurality of packets to be stored in 
the target buffer," a "sequence number for the block of 
data" and "IP source and destination addresses and TCP 
port numbers" are all "communication control 
information." The specification of the '683 patent also 
supports this definition (see, e.g., column 5, lines 8-15). 
Indeed, there is no teaching or suggestion in the '683 
patent that the "flow specification" is anything other than 
"communication control information." Therefore, Count 1 
would have anticipated and rendered obvious claim 1, and 
vice-versa. 


2. The method of claim 1 , wherein the control field in 
the packet includes a packet header. 

Applicants submit that Count 1 would have rendered 
obvious claim 2, because a person having ordinary skill in 
the art would have thought that a "control field identifying 
a packet" would commonly be a "packet header." 


3 . The method of claim 1 , wherein the multi-layer 
network protocol comprises TCP/IP, and the confrol field 
comprises a TCP/IP header. 

Applicants submit that Count 1 would have rendered 
obvious claim 3, because TCP/IP was a common network 
protocol and header type. 


8. The method of claim 1 , wherein the flow specification 
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includes a sequence number for the block of data. 

Applicants submit that Count 1 would have rendered 
obvious claim 8, because sequence numbers are a common 
way to identify data that is transferred over a network. For 
example, TCP is known to require a control block of 
"communication control information," sometimes called a 
TCB, which includes sequence numbers that are used for 
various tasks including flow control. 


9. The method of claim 8, wherein the flow specijScation 
includes IP source and destination addresses and TCP port 
numbers. 

Applicants submit that Count 1 would have rendered 
obvious claim 9, because IP source and destination 
addresses and TCP port numbers are a common way to 
identify network data flows. For example, TCP is known 
to require a control block of "communication control 
information," sometimes called a TCB, which includes IP 
source and destination addresses and TCP port numbers. 


Count 2. A method for 
transferring data on a 
network from a data source 
to an end station executing 
a multi-layer network 
protocol, including a 
network layer and at least 
one higher layer, through a 
network interface on the 
end station, comprising: 

receiving in the network 
interface a packet which 
carries a data payload from 
a block of data in the data 
source, and a control field 
identifying the packet; 

determining based on the 
control field in the network 
interface whether the packet 
matches communication 
control information, and if 
so transferring the data 
payload in the packet 
directly to a target buffer 


4. The method of claim 1, including prior to receiving 
the packet, allocating the target buffer for the plurality of 
packets, and notifying the network interface of the 
allocated target buffer. 

Claim 4, written in independent form to include the 
limitations of claim 1, is essentially identical to Count 2, 
except for the term "communication control information" 
in the Count compared with the term "flow specification" 
in the claim. Applicants note that claim 4 also has the 
definite article "the" preceding the term "plurality of 
packets," whereas Count 2 instead has the indefinite 
article "a" preceding the term "plurality of packets." 

As noted above regarding claim 1, a "flow specification" 
is defined to include various items of "communication 
control information," and there is no teaching or 
suggestion in the '683 patent that the "flow specification" 
is anything other than "communication control 
information." For these reasons, applicants submit that 
Count 2 would have anticipated or rendered obvious claim 
4, and vice- versa. 
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assigned by a process at a 
layer higher than the 
network layer; 

including prior to 
receiving the packet, 
allocating the target buffer 
for a plurality of packets, 
and notifying the network 
interface of the allocated 
target buffer. 



Count 3. A method for 
transferring data on a 
network from a data source 
to an end station executing 
a multi-layer network 
protocol, including a 
network layer and at least 
one higher layer, through a 
network interface on the 
end station, comprising: 

receiving in the network 
interface a packet which 
carries a data payload from 
a block of data in the data 
source, and a control field 
identifying the packet; 

determining based on the 
control field in the network 
interface whether the packet 
matches communication 
control information, and if 
so transferring the data 
payload in the packet 
directly to a target buffer 
assigned by a process at a 
layer higher than the 
network layer; 

wherein the network 
interface is coupled to a 
network medium supporting 
a maximum packet size, and 
including transmitting a 
request from an application 
for transfer of a block of 
data from the data source, 



5. The method of claim 1 , the network interface is 
coupled to a network medium supporting a maxunum 
packet size, and including transmitting a request from an 
application for transfer of a block of data from the data 
source, the block of data having a length potentially 
greater than the maximum packet size for the medium. 

Claim 5, written in independent form to include the 
limitations of claim 1, is essentially identical to Count 3, 
except for the term "communication control information" 
m the Count compared with the term "flow specification" 
m the claim. 

As noted above regarding claim 1, a "flow specification" 
is defined to include various items of "communication 
control information," and there is no teaching or 
suggestion in the '683 patent that the "flow specification" 
is anything other than "communication control 
information." For these reasons, applicants submit that 
Count 3 would have anticipated and rendered obvious 
claim 5, and vice- versa. 
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the block of data having a 
length potentially greater 
than the maximum packet 
size for the medium. 






6. The method of claim 5, including notifying the 
network interface in response to the request of a flow 
specification for the block of data according to the multi- 
layer network protocol, and wherein the step of receiving 
the packet includes identifying packet using the flow 
specification. 

Claim 6, written in independent form to include the 
limitations of claim 5, is similar to Count 3, but rewritten 
claim 6 also includes the lunitation "including notifying 
the network interface in response to the request of a flow 
specification for the block of data according to the multi- 
layer network protocol, and wherein the step of receiving 
the packet mcludes identifying packet using the flow 
specification." 

Applicants submit that Count 3 would have anticipated or 
rendered obvious claim 6, because Count 3 recites 
"determining based on the control field in the network 
uiterface whether the packet matches communication 
control information," whereas claim 6 recites in part 
"notifying the network interface . . .of a flow specification" 
and "identifying packet using the flow specification." 
Assuming the "flow specification" element equates to 
"communication control information," as explained above 
regarding claim 1, "notifying" and "identifying (a) packet 
using" this element would seem to be mherent in 
"determining based on the control field in the network 
mterface whether the packet matches commvinication 
control information." If somehow this is not considered 
mherent, it would have been obvious to "notify. . . the 
network interface . . .of a flow specification" and 
"identify. . . (a) packet using the flow specification" to 
accomplish the recitation of "determinmg based on the 
control field in the network interface whether the packet 
matches communication control information." 




7. The method of claim 6, wherein the network protocol 
comprises TCP/IP, and the flow specification includes a 
sequence number of a first byte from the plurality of 
packets to be stored in the target buffer. 
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Applicants note that claim 7 depends from claim 6, but 
claim 6 lacks antecedent basis for the term "the plurality 
of packets." 

Claim 7, written in independent form to include the 
limitations of claim 4, is similar to Count 3, but rewritten 
claim 7 also includes the limitation "wherein the network 
protocol comprises TCP/IP, and the flow specification 
includes a sequence number of a first byte from the 
plurality of packets to be stored in the target buffer." 

TCP/IP was a well known network protocol, which used 
sequence numbers to identify all bytes of data flow. For 
example, TCP is known to require a confrol block of 
"communication control information," sometimes called a 
TCB, which includes sequence numbers that are used for 
various tasks including flow control, which would 
necessarily include a "sequence number of a first byte 
from the pliirality of packets." As discussed above for 
claim 1, the "flow specification" element equates to 
"communication control information." Thus, the use of 
the well known network protocol TCP, which would have 
been obvious, would have required the claimed sequence 
nimiber as part of the "flow specification" that is 
"communication control information" and so Count 3 
would have rendered obvious claim 7. , 



ii. Claim Chart Comparing Pending Claims 41-49 with the Counts 
Applicants submit the following claim chart comparing pending claims 41-49 
with the Counts. 



Pending Claim Correspondence to Counts 



Count 


Claims in the present application that correspond to the 
Count 


Count 1 . A method for 
fransferring data on a 
network from a data source 
to an end station executmg 
a multi-layer network 
protocol, including a 


41. A method for fransferring data on a network from a 
data source to an end station executmg a multi-layer 
network protocol, including a network layer and at least 
one higher layer, through a network interface on the end 
station, comprising: 

receiving in the network interface a packet which 
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network layer and at least 
one higher layer, through a 
network interface on the 
end station, comprising: 

receiving in the network 
interface a packet which 
carries a data payload from 
a block of data in the data 
source, and a control field 
identifying the packet; 

determining based on the 
control field in the network 
interface whether the packet 
matches communication 
control information, and if 
so transferring the data 
payload in the packet 
directly to a target buffer 
assigned by a process at a 
layer higher than the 
network layer. 



carries a data payload from a block of data in the data 
source, and a control field identifying the packet; 

determining based on the control field in the network 
interface whether the packet matches a transmit control 
block (TCB), and if so transferring the data payload in the 
packet directly to a target buffer assigned by a process at a 
layer higher than the network layer. 

Claim 41 is identical to Comt 1, except for the term 
"communication control information" in the Count 
compared with the term "transmit control block (TCB)" in 
the claim. 

Applicants submit that Count 1 would have anticipated or 
rendered obvious claim 41, and vice- versa. For example, 
claim 47, which depends indirectly from claim 1 , defines 
that the "TCB" includes "a sequence number of a first byte 
from the plurality of packets to be stored in the target 
buffer." Similarly, claim 48, which depends from claim 
41, defines that the "TCB" includes "a sequence number 
for the block of data." Claim 49, which depends indirectly 
from claim 41, defines that the "TCB" includes "IP sovirce 
and destination addresses and TCP port numbers." A 
"sequence number of a first byte from the plurality of 
packets to be stored in the target buffer," a "sequence 
number for the block of data" and "IP source and 
destination addresses and TCP port numbers" are all 
"communication control information." The specification 
of parent application number 60/061,809 (the '809 app.), 
which was incorporated by reference in the present 
application, also supports the conclusion that the TCB 
includes "communication confrol information." See, e.g., 
page 6, line 32 - page 7, line 10. 



42. The method of claim 4 1 , wherein the control field in 
the packet includes a packet header. 

Applicants submit that Count 1 would have rendered 
obvious claim 42, because a person having ordinary skill 
in the art would have thought that a "confrol field 
identifying a packet" would commonly be a "packet 
header." 



43 . The method of claim 4 1 , wherein the multi-layer 
network protocol comprises TCP/IP, and the confrol field 
comprises a TCP/IP header. 
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Applicants submit that Count 1 would have rendered 
obvious claim 43, because TCP/IP was a common network 
protocol and header type. 


48. The method of claim 41, wherein the TCB includes a 
sequence number for a block of data. 

Applicants submit that Coxmt 1 would have rendered 
obvious claim 48, because sequence numbers are a 
common way to identify data that is transferred over a 
network. For example, TCP maintains a control block, 
sometimes called a TCB, which includes sequence 
numbers that are used for various tasks including flow 
control. Sequence numbers are thus known to be 
"conmiunication control information" like that defined in 
Count 1. 


49. The method of claim 48, wherein the TCB includes 
IP source and destination addresses and TCP port 
numbers. 

Applicants submit that Count 1 would have rendered 
obvious claim 49, because IP source and destmation 
addresses and TCP port numbers are a common type of 
"communication control information." For example, TCP 
maintains a control block, sometimes called a TCB, which 
mcludes "IP source and destination addresses and TCP 
port numbers" that are used for various tasks including 
identification and control of network data flows. "IP 
source and destination addresses and TCP port numbers" 
are thus known to be "communication control 
information" like that defined in Count 1 . 


Count 2. A method for 
transferring data on a 
network from a data source 
to an end station executing 
a multi-layer network 
protocol, including a 
network layer and at least 
one higher layer, through a 
network interface on the 
end station, comprising: 

receiving in the network 
interface a packet which 


44. The method of claim 41 , including prior to receiving 
the packet, allocating the target buffer for a plurality of 
packets, and notifying the network interface of the 
allocated target buffer. 

Claim 44, written in independent form to include the 
limitations of claim 41, is essentially identical to Count 2, 
except for the term "communication control information" 
m the Coxmt compared with the term "TCB" in the claim. 
As noted above, the term "TCB" includes "communication 
control information." 
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carries a data payload from 
a block of data in the data 
source, and a control field 
identifying the packet; 

determining based on the 
control field in the network 
interface whether the packet 
matches communication 
control information, and if 
so transferring the data 
payload in the packet 
directly to a target buffer 
assigned by a process at a 
layer higher than the 
network layer; 

including prior to 
receiving the packet, 
allocating the target buffer 
for a plurality of packets, 
and notifying the network 
interface of the allocated 
target buffer. 



Applicants submit that Count 2 would have anticipated or 
rendered obvious claim 44, and vice- versa. 



Count 3. A method for 
transferring data on a 
network from a data source 
to an end station executing 
a multi-layer network 
protocol, including a 
network layer and at least 
one higher layer, through a 
network interface on the 
end station, comprising: 

receiving in the network 
interface a packet which 
carries a data payload from 
a block of data in the data 
source, and a control field 
identifying the packet; 

determining based on the 
control field in the network 
interface whether the packet 
matches communication 
control information, and if 
so transferring the data 
payload in the packet 



45 . The method of claim 4 1 , the network interface is 
coupled to a network medium supporting a maximum 
packet size, and including transmitting a request from an 
application for transfer of a block of data from the data 
source, the block of data having a length greater than the 
maximum packet size for the medium. 

Claim 45, written in independent form to include the 
limitations of claim 41, is essentially identical to Count 3, 
except for the term "communication control information" 
in the Count compared with the term "TCB" in the claim. 
As noted above, tiie term "TCB" includes "communication 
control information." 

Applicants submit that Count 3 would have anticipated or 
rendered obvious claim 45, and vice- versa. 
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directly to a target buffer 
assigned by a process at a 
layer higher than the 
network layer; 

wherein the network 
interface is coupled to a 
network medium supporting 
a maximum packet size, and 
including transmitting a 
request from an application 
for transfer of a block of 
data from the data source, 
the block of data having a 
length potentially greater 
than the maximum packet 
size for the medium. 






46. The method of claim 45, including notifying the 
network interface in response to the request of the TCB for 
the block of data according to the multi-layer network 
protocol, and wherein the step of receiving the packet 
includes identifying packet using the TCB. 

Claim 46, written in independent form to include the 
limitations of claim 45, is similar to Count 3, but rewritten 
claim 46 also includes the limitation "including notifying 
the network interface in response to the request of a TCB 
for the block of data according to the multi-layer network 
protocol, and wherein the step of receiving the packet 
includes identifying packet using the TCB." 

Applicants submit that claim 46 would have anticipated or 
rendered obvious Count 3, because Count 3 recites 
"determining based on the control field in the network 
interface whether the packet matches communication 
control information," whereas claim 46 recites in part 
"notifying the network interface . . .of a TCB" and 
"identifying a packet using the TCB." Assuming the 
"TCB" element includes "communication control 
information," as explained above regarding claim 41, 
"notifying" and "identifying a packet using" this element 
would seem to be inherent in "determining based on the 
control field in the network interface whether the packet 
matches the TCB." If somehow this is not considered 
inherent, it would have been obvious to "notify. . . the 
network interface . . .of commimication control 
information" and "identify. . . (a) packet using the 
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communication control information to accomplish the 
recitation of "determining based on the control field in the 
network interface whether the packet matches the TCB." 




47. The method of claim 46, wherein the network 
protocol comprises TCP/IP, and the TCB includes a 
sequence number of a first byte fi-om a plurality of packets 
to be stored in the target buffer. 

Claim 47, written in independent form to include the 
limitations of claim 44, is similar to Count 2, but rewritten 
claim 47 also includes the limitation "wherein the network 
protocol comprises TCP/IP, and the TCB includes a 
sequence number of a first byte fi-om the plurality of 
packets to be stored in the target buffer." 

TCP/IP was a well known network protocol, which used 
sequence mmibers to identify all bytes of data flow. For 
example, TCP is known to require a control block of 
"communication control information," sometimes called a 
TCB, which includes sequence numbers that are used for 
various tasks including flow control, which would 
necessarily include a "sequence number of a first byte 
from the pliirality of packets." As discussed above for 
claim 41, the "TCB" element equates to "communication 
control information." Thus, the use of the well known 
network protocol TCP, which would have been obvious, 
would have required the claimed sequence number as part 
of the "TCB" that is "communication control information" 
and so claim 47 would have rendered obvious Count 3. 



iii. Claim Chart Comparing Claims 1-9 of the '683 Patent with Pending 
Claims 41-49 
The Office communication states: 

4. The applicant should provide evidence to support the conclusion of 
obviousness of the claim mappings. Specifically the applicant should 
support evidence why it is obvious to use a transmit control block (TCB) 
in the pending claims instead of a flow specification in the patent 
(6,246,683) and vice versa. 
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Applicants submit the following claim chart comparing claims 1-9 of the '683 
patent with pending claims 41-49, including intrinsic evidence from the '683 patent and 
from the pending application. 



Claims 1-9 of the '683 Patent Claims Compared to the Pending Claims 



Claim in the '683 Patent 



Pending Claim 



1 . A method for transferring data on a 
network from a data source to an end 
station executing a multi-layer network 
protocol, including a network layer and at 
least one higher layer, through a network 
interface on the end station, comprising: 

receiving in the network interface a 
packet which carries a data payload from a 
block of data in the data source, and a 
control field identifying the packet; 

determining based on the control field 
in the network interface whether the packet 
matches communication control 
information, and if so fransferring the data 
payload in the packet directly to a target 
buffer assigned by a process at a layer 
higher than the network layer. 

Pending claim 41 is identical to claim 1 of 
the '683 patent, except for the term 
"transmit control block (TCB)" in claim 41 
compared with the term "flow 
specification" in claim 1. 

Applicants submit that pending claim 41 
would have rendered obvious claim 1 of 
the '683 patent. For example, claim 47, 
which depends indirectly from claim 41, 
defines that the "TCB" includes "a 
sequence number of a first byte from the 
plurality of packets to be stored in the 
target biiffer," whereas claim 7, which 
depends indirectly from claim 1, defines 
that the "flow specification" includes the 
exact same things. Similarly, claim 48, 
which depends from claim 41, defines that 
the "TCB" includes "a sequence number 



41. A method for transferring data on a 
network from a data source to an end 
station executing a multi-layer network 
protocol, including a network layer and at 
least one higher layer, through a network 
interface on the end station, comprising: 

receiving m the network interface a 
packet which carries a data payload from a 
block of data in the data source, and a 
control field identifying the packet; 

determining based on the control field m 
the network interface whether the packet 
matches a fransmit control block (TCB), 
and if so fransferring the data payload in 
the packet dfrectly to a target buffer 
assigned by a process at a layer higher than 
the network layer. 

Claim 1 of the '683 patent is identical to 
pending claim 41, except for the term "flow 
specification" in claim 1 compared with the 
term "fransmit confrol block (TCB)" in 
claim 41. 

Applicants submit that claim 1 of the '683 
patent may have rendered obvious pending 
claim 41 . For example, claim 7, which 
depends indirectly from claim 1, defines 
that the "flow specification" includes "a 
sequence number of a first byte from the 
plurality of packets to be stored in the 
target buffer," whereas claim 47, which 
depends indirectly from claim 41, defines 
that the "TCB" includes the exact same 
things. Similarly, claim 8, which depends 
from claim 1, defines that the "flow 
specification" includes "a sequence number 



Reply to Office Communication 
App. No. 09/692,561 



18 



for the block of data," whereas claim 8, 
which depends from claim 1, defines that 
the "flow specification" includes the exact 
same things. Further, claim 49, which 
depends indirectly fi-om claim 41, defines 
that the "TCB" includes "LP source and 
destination addresses and TCP port 
numbers," whereas claim 9, which depends 
indirectly from claim 1, defines that the 
"flow specification" includes the exact 
same things. Thus, the only terms that 
differ between pending claim 41 and claim 
1 of the '683 patent actually are defined to 
include the same items. 

Moreover, according to page 6, lines 38-42 
of the '809 app., "A TCB is a structure that 
contains the entire context associated with 
a connection. This includes the source and 
destination IP addresses and source and 
destination TCP ports that define the 
connection. It also contains information 
about the connection itself such as the 
current send and receive sequence 
numbers, and the first-hop MAC address, 
etc." 

Further, according to page 49, lines 42-44 
of the '809 app., "A TCB is associated 
with an input fi-ame when the firame's 
source and destination IP addresses and 
source and destmation ports match that of 
the TCB." 

As stated on page 8, lines 9-12 of the '809 
app., "When this small amount of data is 
passed up to the client, and it returns with 
the address in which to put the remainder 
of the data, oxoi host transport driver will 
pass that address to the INIC which will 
DMA the remainder of the data into its 
final destination." 

Similarly, page 19, line 6 - page 23, line 4 
of the '809 app. describes how a "MDL" 
(memory descriptor list) is obtained firom 
tiie host and passed as a "receive request" 
including a "TCP context identifier" (i.e., a 
TCB identifier) to the network interface. 



for the block of data," whereas claim 48, 
which depends from claim 41, defines that 
the "TCB" includes the exact same things. 
Further, claim 9, which depends indirectly 
fi-om claim 1, defines that the "flow 
specification" includes "IP source and 
destination addresses and TCP port 
numbers," whereas claim 49, which 
depends indirectly from claim 41, defines 
that the "TCB" includes the exact same 
things. Thus, the only terms that differ 
between claim 1 of the '683 patent and 
pending claim 41 actually are defined to 
include the same items. 

Moreover, according to column 5, luies 9- 
13 of the '683 patent, "the call made by the 
TCP/IP stack sends down to the MAC 
driver the flow speciflcation estabhshed for 
this read beforehand, including the source 
and destination IP addresses, and the 
source and destination port numbers (i.e. 
sockets)." 

Further, according to column 2, lines 25-31 
of the '683 patent, "Upon receiving a 
packet, the control data of the packet is 
read in the network interface, and if the 
packet belongs to a flow specification 
subject of the bypass, the data payload of 
the packet is transferred to a buffer 
assigned by a layer higher in the stack, 
preferably by the application or file system, 
bypassing one or more intermediate buffers 
of the protocol stack." Similarly, 
according to column 2, Hues 41-45 of the 
'683 patent, "At the network interface, the 
plurality of packets is received, and their 
control fields, such as TCP/IP headers, are 
read. If they fall within the set up flow 
specification, the payloads are bypassed 
directly into the target buffer." Likewise, 
as stated in column 5, lines 16-19 of the 
'683 patent, "The target buffer specifies 
where the payload should be stored when 
possible by the network interface card. The 
flow specification specifies how to identi:^^ 
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for "transferring the data payload in the 
packet directly to a target buffer assigned 
by a process at a layer higher than the 
network layer" upon "determining based 
on the control field in the network interface 
whether the packet matches a transmit 
control block (TCB)." 
Therefore, claim 1 of the '683 patent 
differs from claim 41 of the '809 app. only 
in the term "flow specification" compared 
to TCB, but those terms are defined to 
include the same items and perform the 
same function in the claim. It would have 
been obvious for one of ordinary skill in 
the art to simply substitute the term "flow 
specification" for the term "TCB" to 
achieve the same result in claim 1 as that 
defined in claim 41. See MPEP § 2141. 



packets that are part of this session." 

Although there is no difference between the 
term "flow specification" as used in claim 
1 of the '683 patent and the term "TCB" as 
used in pending claim 41 , the '683 patent 
specification explains that the "flow 
specification" is only passed from a host 
computer to its network interface when a 
"read request" is made by the computer to a 
remote computer, with the "flow 
specification" serving as a guide to the 
response to that "read request," whereas the 
pending application explains that the 
"TCB" is established by a host computer 
and passed to its network interface for use 
in transmitting data as well as in receiving 
data for either a "read request" or a "write 
request," with the "destination" buffer for a 
"read request" associated with the TCB 
held by the network interface at a time 
immediately prior to data transfer between 
the host and the network interface. 
Similarly, in transmitting data, the TCB is 
passed out to the network interface first, 
and the target buffer from which the data is 
sent is associated with the TCB 
immediately prior to data being 
transmitted. 



Because transferring a TCB that may have 
rapidly changing and interrelated state fi-om 
a host to its network interface is more 
difficult than transferring a read request 
along with its related IP addresses and TCP 
ports, and because transferring such a TCB 
is usefiil not only for a read request but for 
a write request as well as for transmitting 
data, there is a question whether pending 
claim 41 is obvious over claim 1 of the 
'683 patent. The question is whether these 
differences in the specifications should be 
read into the claims. Because there is no 
explicit definition of the term "flow 
specification" or the term "TCB" in the 
specifications (although the dependent 



Reply to Office Communication 
App. No. 09/692,561 



20 





claims provide some definitions) and 
because there is no prosecution history that 
requires limitations of the specifications to 
be read into the claims, pending claim 4 1 
and claim 1 of the '683 patent should be 
read broadly, so that pending claim 41 
would have been obvious over claim 1 of 
the '683 patent. 


2. The method of claim 1 , wherein the 
control field in the packet includes a packet 
header. 

Applicants submit that pending claim 42 
would have rendered obvious claim 2 of 
the '683 patent because the claims are 
identical except for the term "flow 
specification" compared to the term "TCB" 
as discussed above with regard to the 
independent claims. 


42. The method of claim 41 , wherein the 
control field in the packet includes a packet 
header. 

Applicants submit that claim 2 of the '683 
patent would have rendered obvious 
pcnd-iiig cl^m 42 l)6C3.usc tlic claims bxq 
identical except for the term "flow 
specification" compared to the term "TCB" 
as discussed above with regard to the 
independent claims. 


3 . The method of claim 1 , wherein the 
multi-layer network protocol comprises 
TCP/IP, and the control field comprises a 
TCP/IP header. 

Applicants submit that pending claim 43 
would have rendered obvious claim 3 of 
the '683 patent because the claims are 
identical except for the term "flow 
specification" compared to the term "TCB" 
as discussed above with regard to the 
independent claims. 


43 . The method of claim 4 1 , wherein the 
multi-layer network protocol comprises 
TCP/IP, and the control field comprises a 
TCP/IP header. 

Applicants submit that claim 3 of the '683 
patent would have rendered obvious 
pending claim 43 because the claims are 
identical except for the term "flow 
specification" compared to the term "TCB" 
as discussed above with regard to the 
independent claims. 


4. The method of claim 1, including prior 
to receiving the packet, allocating the 
target buffer for the plurality of packets, 
and notifying the network interface of the 
allocated target buffer. 

Applic3Jits submit tlid-t pcn.d.iii§ clsim 44 
would have rendered obvious claun 4 of 
the '683 patent because the claims are 
essentially identical except for the term 
"flow specification" compared to the term 
"TCB" as discussed above with regard to 


44. The method of claim 41 , including 
prior to receiving the packet, allocating the 
target buffer for a plurality of packets, and 
notifying the network interface of the 
allocated target buffer. 

Applicsnts submit th^t cidim. 4 of the '683 
patent would have rendered obvious 
pending claim 44 because the claims are 
essentially identical except for the term 
"flow specification" compared to the term 
"TCB" as discussed above with regard to 
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the independent claims. 


the independent claims. 


5. The method of claim 1, the network 
interface is coupled to a network medium 
supporting a maximum packet size, and 
including transmitting a request from an 
application for transfer of a block of data 
from the data source, the block of data 
having a length potentially greater than the 
maximum packet size for the medium. 

Applicants submit that pending claim 45 
would have rendered obvious claim 5 of 

identical except for the term "flow 
specification" compared to the term "TCB" 
as discussed above with regard to the 
independent claims. 


45. The method ofclaim 41, the network 
interface is coupled to a network medium 
supporting a maximum packet size, and 
including transmitting a request from an 
application for fransfer of a block of data 
from the data source, the block of data 
having a length greater than the maximvim 
packet size for the medium. 

Applicants submit that claim 5 of the '683 
patent would have rendered obvious 
pending cIb-Iiii 45 becouse the cl^ms dre 
identical except for the term "flow 
specification" compared to the term "TCB" 
as discussed above with regard to the 
independent claims. 


6. The method of claun 5, including 
notifying the network interface in response 
to the request of the flow specification for 
the block of data according to the multi- 
layer network protocol, and wherein the 
step of receiving the packet includes 
identifying packet using the flow 
specification. 

Applicants submit that pending claim 46 
would have rendered obvious claim 6 of 
the '683 patent because the cl3.inis btc 
essentially identical except for the term 
"flow specification" compared to the term 
"TCB" as discussed above with regard to 
the independent claims. 


46. The method of claim 45, including 
notifying the network interface in response 
to the request of a TCB for the block of 
data according to the multi-layer network 
protocol, and wherem the step of receiving 
the packet includes identifying packet 
using the TCB. 

Applicants submit that claim 6 of the '683 
patent would have rendered obvious 
pendmg claim 46 because the claims are 
essenti&lly identicBl except for the term 
"flow specification" compared to the term 
"TCB" as discussed above with regard to 
the independent claims. 


7. The method of claun 6, wherein the 
network protocol comprises TCP/IP, and 
the flow specification includes a sequence 
number of a first byte from the plurality of 
packets to be stored in the target buffer. 

AppUcants submit that pending claim 47 
would have rendered obvious claim 7 of 
the '683 patent because the claims are 
essentially identical except for the term 


47. The method of claim 46, wherein the 
network protocol comprises TCP/IP, and 
the TCB includes a sequence number of a 
first byte from a plurality of packets to be 
stored in the target buffer. 

Applicants submit that claim 7 of the '683 
patent would have rendered obvious 
pendmg claim 47 because the claims are 
essentially identical except for the term 
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"flow specification" compared to the term 
"TCB" as discussed above with regard to 
the independent claims. 


"flow specification" compared to the term 
"TCB" as discussed above with regard to 
the independent claims. 


8. The method of claim 1 , wherein the 
flow specification includes a sequence 
number for the block of data. 

Applicants submit that pending claim 48 
would have rendered obvious claim 8 of 
tli6 683 pd^tctit lDccd.u.s6 the cls^inis src 
essentially identical except for the term 
"flow specification" compared to the term 
"TCB" as discussed above with regard to 
the independent claims. 


48. The method ofclaim 41, wherein the 
TCB includes a sequence number for a 
block of data. 

Applicants submit that claim 8 of the '683 
patent would have rendered obvious 
pcnciiiig cld^irn. 48 becBUse the cl3.inis rtc 
essentially identical except for the term 
"flow specification" compared to the term 
"TCB" as discussed above with regard to 
the independent claims. 


9. The method of claim 8, wherein the 
flow specification includes IP source and 
destination addresses and TCP port 
numbers. 

Applicants submit that pending claim 49 
would have rendered obvious claim 9 of 
the ^683 patent because the claims are 
essentially identical except for the term 
"flow specification" compared to the term 
"TCB" as discussed above with regard to 
the independent claims. 


49. The method of claim 8, wherein the 
TCB includes IP source and destination 
addresses and TCP port numbers. 

Applicants submit that claim 9 of the '683 
patent would have rendered obvious 
pending claim 49 because the claims are 
essentially identical except for the term 
"flow specification" compared to the term 
"TCB" as discussed above with regard to 
the independent claims. 



F. Detailed Explanation why Applicants Will Prevail on Priority 
Applicants note that the instant application number 09/692,561 is a continuation 
of application number 09/067,544, which was filed April 27, 1998, several days prior to 
the filing date of the '683 patent. The present application also incorporates by reference 
parent application number 09/067,544. Because applicants are entitled to the benefit of 
filing date of parent application nimiber 09/067,544 under 37 CFR § 1.601(g), applicants 
are the Senior Party according to 37 CFR §41 .201 and are entitled to the presumption of 
priority under 37 CFR §41 .207(a)(1). 

Applicants also point out that the instant application number 09/692,561, as well 
as parent application nxunber 09/067,544, claim priority from provisional application 
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number 60/061,809, which was filed October 14,1997, more than six months prior to the 
filing date of the '683 patent. Moreover, applicants note that both the instant application 
number 09/692,561 and parent application number 09/067,544 incorporate by reference 
provisional application number 60/061,809. Because applicants are entitled to the benefit 
of filing date of provisional application number 60/061,809 under 37 CFR §1 .601(g), 
applicants are the Senior Party according to 37 CFR §41.201 and are entitled to the 
presumption of priority under 37 CFR §4 1.207(a)(1). 

Applicants show in detail below why each of interfering claims 41-49 is entitled 
to the benefit of the filing date of parent application number 09/067,544, as well as being 
entitled to the benefit of the filing date of provisional application number 60/061,809. In 
the following claim chart, applicants list disclosures in applicants' applications that 
provide support for the pending claims. For convenience, the present application is 
labeled Al, parent application number 09/067,544 is labeled A2, and provisional 
application number 60/061,809 is labeled A3. Because Al is a continuation of A2 and 
has an identical specification (and incorporates by reference A2), aside from a shifting of 
line niunbers due to an extra priority claim at the beginning of A2, for clarity and 
simplicity applicants will not, in the following claim chart, list disclosures in Al that are 
essentially redundant with those of A2. 

G. Showing of Support in Earlier Applications for the Pending Claims 
Applicants submit the following chart showing support in earlier applications 
(Al, A2 and A3) for pending claims 41-49. 



Showing of Support in Earlier Applications for the Pending Claims 



Pending Claims 


Disclosure in Applicants' Applications 


41. (New) A method for transferring 
data on a network from a data source to 
an end station 


[A2, page 7, line 8 ttirougti page 8, line 8] Figures 1-8 relate to a "first embodiment'. 
[A2, page 9, Fig. 1, and lines 2-8] In Fig, 1, remote host 22 is a data source; and host 20 
is an end station. Host 20 includes a CPU 28 and a CPD 30. As illustrated, CPD 30 
interfaces host 20 to network 25. 

[A3, page 2, lines 36-37] "A 64k SMB request (write or read-reply) is typically made up of 
44 TCP segments when running over Ethernet" 

[A3, page 3, lines 34-35] "Alacritech was formed with the idea that the network 
processing described atiove could be offloaded onto a cost-effective Intelligent Network 
Interface Card (INIC)." 

[A3, page 4, lines 18-19] Source IP address denotes a data source. 
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executing a multi-layer network protocol, 
including a network layer and at least one 
higher layer, 

through a network interface on the end 
station, comprising: 


[A3, page 6, lines 1-20] The figure shows an end station. 

[A2, page 9, lines 13-15] CPU 28 of host 20 executes a protocol processing "stack" 44. 
The "stack 44° includes a "network layer" 38 and a "transport layer" 40. 
[A3, page 6] The figure shows a multi-layer network protocol, including a network layer 
and at least one higher layer. 

[A3, page 18, lines 22-26] 'This section outlines the design specification for the Alacritech 
TCP (ATCP) transport driver. The ATCP driver consists of three components: 1 . The 
bulk of the protocol stack is based on the FreeBSD TCP/IP protocol stack. This code 
performs the Ethernet, ARP, IP, ICMP, and (slow path) TCP processing for the driver..." 

[A2, FIG. 1] CPD 30 interfaces host 20 to network 25. 

[A3, page 6] The figure shows the INIC interfacing the end station to the Ethemet 

network. 


receiving in the network interface a 
packet which carries a data payload from 
a block of data in the data source, and a 
control field identifying the packet; 


[A2, page 1 1 , lines 14-1 8] A "TCP/IP message" is "received by the host from the network" 
in the form of many separate "frames" or "packets" (an initial packet, and subsequent 
packets). 

[A2, page 4, line 20-23] "Each layer of the receiving host recognizes and manipulates 

only the headers associated with that layer, since to that layer the higher layer control 

data is included with and indistinguishable from the payload data." 

[A2, page 15, lines 4-6] One of the "subsequent packets" is received from network 25 by 

CPD 30. This packet includes a "packet header" and "data". 

[A2, page 12, lines 1-3] "...each packet conventionally includes a portion of data being 

transferred, as well as headers for each of the protocol layers and markers for positioning 

the packet relative to the rest of the packets of this message", 

[A3, page 2, lines 36-37] "A 64k SMB request (write or read-reply) is typically made up of 

44 TCP segments when running over Ethernet" 

[USP 6,246,683, column 2, lines 59-65] "the process for requesting the transfer of a file 
from a data source involves issuing a read request according to higher layer protocol, 
such as the READ RAW SMB (server message block) command specified according to 
the Common Internet File System protocol (See, paragraph 3.9.35 of CIFS/1 .0 draft dated 
Jun. 13, 1996) executed in Windows platforms." 

[A3, page 2, lines 29-30] " The TCP connection object must be located when a given 
TCP segment arrives, IP header checksums must be calculated. .." 


determining based on the control 
field in the network interface 

whether the packet matches a transmit 
control block (TCB), 


[A2, page 15, lines 4-12] The packet "header" of the subsequent packet is "parsed to 
create a summary of the message packet and a hash for finding a corresponding CCB..." 
[A3, page 4, lines 1-10] NIC processes IP and TCP headers. 
[A3, page 7, lines 13-16] "When a frame is received by the INIC, it must verify it 
completely before it even determines whether it belongs to one of its TCBs or not. This 
includes all header validation (is it IP, 1PV4 or V6, is the IP header checksum con-ect, is 
the TCP checksum con^ect, etc)." 

The term "TCB" corresponds to the temi "CCB" as the term is used in [A2]. 
[A2, page 24, lines 13-18] "A CCB includes connection and state information regarding 
the protocol layers and packets of the message. Thus a CCB can include source and 
destination media access control (IVIAC) addresses, source and destination IP or IPX 
addresses, source and destination TCP or SPX ports, TCP variables such as timers, 
receive and transmit windows for sliding window protocols, and information denoting the 
session layer protocol". 

[A2, page 15, lines 9-12] " The processor 55 checks for a match between the hash and 
each CCB that is stored in the cache 62 and, finding a match, sends the data (D2) 70 via 
a fast-path directly to the destination in storage 35,..." (emphasis added). 
[A3, page 2, lines 13-18] "When a frame is received by the INIC, it must verify it 
completely before it even determines whether it belongs to one of its TCBs or not. This 
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and if so transferring the data payload In 
the pacl^et directly to a target buffer 
assigned by a process at a layer higher 
than the network layer. 


includes all header validation (is it IP, IPV4 or V6, is the IP header checksum con-ect, is 
the TCP checksum correct, etc). Once this is done It must compare the source and 
destination IP address and the source and destination TCP port with those in each of its 
TCBs to determine If it is associated with one of its TCBs." 
[A3, page 7, lines 16-1 8] "Once this is done it must compare the source and destination 
IP address and the source and destination TCP port with those In each of its TCBs to 
determine if It is associated with one of its TCBs," 

[A2, page 12, line 21 through page 13, line 5] "All received message frames which have 
been detennined by the CPD hardware assist to be fast-path candidates are examined 53 
by the network microprocessor on INIC comparitor circuits to determine whether they 
match a CCB held by the CPD. Upon confirming such a match, the CPD removes lower 
layer headers and sends 69 the remaining application data from the frame directly into 
its final destination in tfte host using direct memory access (DMA) units of the CPD. 
This operation may occur Immediately upon receipt of a message packet, for example 
when a TCP connection already exists..." (emphasis added). 
[A2, page 18, lines 2-3] The "application layer 166... pro v/des a source or destination 
168 for the communication data..." 

[A3, page 3, lines 38-39] "The vast majority of the data is moved directly from the INIC 
into its final destination. A single trip across the system memory bus." 
[A3, page 7, lines 38-39] A received frame's source and destination IP addresses and 
source and destination TCP ports are parsed by the INIC to see If it matches a TCB. 
[A3, page 7, line 42 - page 8, line 44] Landing the received data In its final destination, 
which is a target buffer on the host, is accomplished by passing a upper layer header to 
the host NetBIOS or other upper layer protocol, which returns a memory address that the 
INIC uses to DMA the remainder of the data into as it amves In packets on the INIC that 
match the TCB. 

returns with the address In which to put the remainder of the data, our host transport 
driver will pass that address to the INIC which will DMA the remainder of the data into its 
final destination." 

[A3, page 11, lines 5-34] see entire Fast-path 56k NetBIOS session message example. 
"When the INIC receives the command buffer, it will DMA the remainder of the NetBIOS 
data, as it is received, into the memory address or addresses designated by the host." 


42. The method of Claim 41, 
header. 


headers and sends 69 the remaining application data from the frame directly into its final 
destination in the host..." 

[A3, page 7, lines 13-14] "When a frame is received by the INIC, it must verify it 
completely before It even determines whether it belongs to one of its TCBs or not. This 
Includes all header validation (is it IP, IPV4 or V6, is the IP header checksum correct, is 
the TCP checksum correct, etc)." 


43. The method of claim 41 , 

wherein the multi-layer network protocol 
comprises TCP/IP, 

and the control field comprises a TCP/IP 
header. 


[A2, page 11, line 15] The message being received by the host is a "TCP/IP message". 
[A3, page 18, lines 22-26] "This section outlines the design specification for the Alacritech 
TCP (ATCP) transport driver. The ATCP driver consists of three components: 1 . The 
bulk of the protocol stack Is based on the FreeBSD TCP/IP protocol stack. This code 
performs the Ethernet, ARP, IP, ICMP, and (slow path) TCP processing for the driver..." 

[A2, page 12, lines 1-3] "...each packet conventionally includes a portion of the data 
being transferred, as well as headers for each of the protocol layers..." 
[A2, page 12, lines 9-12] "Selection of fast-path candidates is based on whether the host 
may benefit from this message connection being handled by the CPD, which includes 
determining whether the packet has header bytes denoting particular protocols, such as 
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TCP/IP..." 

[A3, page 7, lines 13-14] "When a frame is received by the INIC, it must verify it 
completely before it even determines whether it belongs to one of its TCBs or not. This 
includes all header validation (is it IP, IPV4 or V6, is the IP header checksum con-ect, is 
the TCP checksum correct, etc)." 


44. The method of claim 41 , 

including prior to receiving the packet, 
allocating the target buffer for a plurality 
of pacl<ets, and notifying the networl< 
interface of the allocated target buffer. 


[A2, page 15, lines 1-5] Prior to receiving the "subsequent packet" as set forth on page 
15, the Initial packef is received. 

[A2, page 14, lines 16-28] The host uses the "initial packet" to "to create a connection 
context for the message, including finding and reserving a destination for the data from 
the message associated with the packet, the context taking the form of a CCB..." 
[A2, page 14, line 18] "The CCB is then sent to the CPD 30 to be saved in cache 62...". 
[A3, page 8, lines 9-12] "When this small amount of data is passed up to the client, and it 
retums with the address in which to put the remainder of the data, our host transport 
driver will pass that address to the INIC which will DMA the remainder of the data into its 
final destination." 

[A3, page 21, lines 14-47] "As soon as the INIC has received a segment containing a 
NETBIOS header, it will forward it up to the TCP driver, along with the NETBIOS length 
from the header.... On receiving the indicated packet, the ATCP driver will call the receive 
handler registered by the TDI client for the connection, passing the actual size of the data 
in the packet from the INIC as "bytes indicated" and the NETBIOS length as "bytes 
available"... In the "large data input" case, where "bytes available" exceeds the packet 
length, the TDI client will then provide an MDL... The ATCP driver will build a "receive 
request" from the MDL information, and pass this to the INIC. This request will contain:... 
A list of physical addresses corresponding to the MDL pages." 


45. The method of claim 41 , 

wherein the network interface is coupled 
to a network medium supporting a 
maximum packet size, 

and including transmitting a request from 

data from the data source, 
the block of data having a length 
potentially greater than the maximum 
packet size for the medium. 


[A2, page 11, lines 14-18] "A large TCP/IP message ... may be received by the host ...in 
a number of separate, approximately 64 KB transfers, each of which may be split into 
many, approximately 1 .5 KB frames or packets for transmission over a network." 
[A3, page 6] The figure shows the INIC coupled to the Ethernet network. 
[A3, page 2, line 37] "Ethemet (1500 byte MTU)." 

[A2, page 29, line 20 through page 30, line 14] SMB is an application. An SMB read 
"request" to read a "100KB file" is transmitted from INIC 150 to server 290, Server 290 
(INIC 200 of server 290) sends the 100 KB file back to INIC 150 as multiple "packets". 
[A3, page 2, lines 36-37] "A 64k SMB request (write or read-reply) is typically made up of 
44 TCP segments when running over Ethernet (1500 byte MTU)." 
[A3, page 4, line 37] "a single 64k SMB write is broken down into 44 1500 byte TCP 
segments, which are in turn broken down into 131 576 byte IP fragments." 


46. The method of claim 45, 

including notifying the network interface 
in response to the request of the TCB for 
the block of data according to the multi- 
layer network protocol, 

and wherein the step of receiving the 
packet includes identifying packet using 
the TCB. 


[A2, page 14, line 14 through page 15, line 3] The first packet received is sent "to the 
host protocol stack 44 for processing. Host stack 44 may use this packet to create a 
connection context for the message., .the context taking the form of a CCB.. .The CCB is 
then sent to the CPD 30 to be saved in cache 62." 

[A2, page 15, lines 4-14] When "a subsequent packet from the same connection as the 
initial packet" is received, the receiving INIC checks "for a match between the hash and 
each CCB that is stored in the cache 62 and, finding a match..." 
[A2, page 24, lines 7-9] "A TCP/IP,., message has a connection that is set up from which 
a CCB is formed by the driver and passed to the INIC for matching with and guiding the 
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fast-path packet to the connection destination 168°. 


47, The method of claim 46, 

wherein the networl< protocol comprises 
TCP/IP, and the TCB Includes a 
sequence number from a plurality of 
packets to be stored in the tarQet buffer. 


[A3, page 6, lines 38-41] "A TCB is a structure that contains the entire context associated 
with a connection. This includes the source and destination IP addresses and source and 
destination TCP ports that define the connection. It also contains information about the 
connection itself such as the current send and receive sequence numbers." 


48. The method of claim 41 , 

wherein the TCB includes a sequence 
number for a block of data. 


[A3, page 6, lines 38-41] "A TCB is a structure that contains the entire context associated 
with a connection. This includes the source and destination IP addresses and source and 
destination TCP ports that define the connection. It also contains information about the 
connection itself such as the current send and receive sequence numbers." 


49, The method of claim 48, 

wherein the TCB includes IP source and 
destination addresses and TCP port 
numbers. 


[A3, page 6, lines 38-41] "A TCB is a structure that contains the entire context associated 
with a connection. This includes the source and destination IP addresses and source and 
destination TCP ports that define the connection. It also contains information about the 
connection itself such as the current send and receive sequence numbers." 



III. Conclusion 

Applicants have responded to each of the items in the Office communication, and 
again respectfully request that an interference with the '683 patent be declared. 



Respectfully submitted, 



/Mark Lauer/ 
Mark Lauer 
Reg. No. 36,578 
6601 KoU Center Parkway 
Suite 245 

Pleasanton, CA 94566 
Tel: (925) 621-2121 
Fax: (925)621-2125 
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